Section: Application Domains

System Interoperability

Recently, MDE has also been used as a solution for system interoperability. In this new context, transformations are performed while systems are in execution. For example, a set of transformations may keep two different tools synchronized, by exchange of structured data or even by interpretation of complex events. This approach revisits tool interoperability by explicitly representing the associated metamodels (if needed, deduced from the tool API or storage format), defining mappings between them and using those mappings to automatically generate transformations between these virtual tool representation. The establishment of correspondences between technical spaces (e.g., Eclipse Modeling and Microsoft DSL tools or OSLO [45] ) follows a similar schema.

For system interoperability it is necessary to provide mechanisms to interoperate with the system components at hand, normally through the APIs they provide. When using MDE for system interoperability, these APIs must be represented and manipulated as models. This model-based view of APIs allow designers to work at a much better abstraction level when bridging between systems or components thanks to the homogeneous treatment of all APIs involved in the software system. As an example, models obtained from API objects could be used in scenarios such as web interoperability and Graphical User Interface (GUI) manipulation at runtime.

Automating the building of these bridges would promote system interoperability. In this context, we have developed API2MoL [14] , which is an approach aimed at automating the implementation of API-MDE bridges. API2MoL is based on a rule-based declarative language to specify mappings between the artefacts of a given API (e.g., API classes in object-oriented APIs) and the elements of a metamodel that represents this API in the MDE technical space. Thus, a mapping definition provides the information which is necessary to build a bridge for a concrete API specification and metamodel.

Another example of bridge between technical spaces is the one developed during the IDM++ project between the MDE and the Constraint Programming (CP) technical spaces to solve configuration problems [22] . The use case supporting this example was focused on the generation of build configurations for Eclipse distributions. In this approach, the information concerning the different components available for the configuration is stored in a configuration model. The model was then converted into a format usable by a configuration CP engine using model transformations techniques. The CP solver was then in charge of finding a configuration solution respecting all dependencies in the model. Finally, an executable configuration description was generated based on the CP feedback to drive the final distribution build.

The main advantage of this kind of approach bridging several technical spaces is the use of the right tooling for the right problem. In particular, for this example of build configuration generation, the dependency resolution between components was clearly a configuration problem. The main motivation for this choice is that configuration is a widely studied problem in the CP community and as a consequence the solutions proposed in this technical space are efficient for this class of problem. On the other side, the concepts used in the CP community are often in a relatively low level of abstraction and MDE can help raising the level of abstraction for describing the problem and so help the final users. This concrete example shows clearly how technical spaces (here MDE and CP) can benefits from each others.